IBIS Macromodel Task Group Meeting date: 25 August 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC * David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Walter relayed a decision being worked on by the Interconnect group. - BIRDs had been proposed for allowing an IBIS file to indicate that it did not contain a description of a complete component, call it "pre-layout". - The Interconnect group had come to the decision that you could have such a pre-layout description, but there would be no special syntax for it. - The IBIS file would still have to contain what looked like a normal [Component] definition ([Pins], etc.) syntactically. In the [Notes], the model maker could indicate, "This is not a shippable product, it is an IBIS container for the following purpose..." -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------------------- Review of Meeting Minutes: - Note: Minutes for August 18th were taken by Randy in Curtis' absence. - Arpad: Does anyone have any comments or corrections? [none] - Arpad: Anyone opposed to approving the minutes? [none] ------------- New Discussion: Item #6: Info, Out, InOut BIRD draft. - Arpad: In recent meetings we've decided this is a notification issue. - We need to make model makers and users aware of portability issues. - Should we introduce a new branch or make use of existing syntax? - If we make use of the existing syntax, how should we refine the rules and describe them? - Bob R: I favor using the existing branch. - We can't dictate that the existing branch not be used for new features. - Arpad: You're afraid people might still use the old method anyway, and we can't enforce use of a new branch? - Bob R: Yes. - Ambrish: I agree with Bob. - Nothing in the spec can force anyone to change their behavior. - Even if we say you shouldn't, there's nothing to stop anyone. - If you forbid Model Specific Info parameters, people could just use In for the same purpose. - The spec should add a line that says it should not be done, and the user and model maker should not expect the EDA tool to read a Model Specific Info parameter, but if it is done then we can't guarantee portability. - Walter: I agree with you and Bob, except for your last statement. - I don't mind if we have a statement that says using a Model Specific Info parameter should not be expected to yield the same behavior on all tools. But I object to saying, "it should not be done." - Arpad: It sounds like we've decided to stick with the existing syntax. - We just need to add something to the spec to point out that certain situations could present an issue. - Radek: There is one simple possibility for notification. - The model maker could put a proper description in the descriptions string. - It's easy to relay that information to the user, and the user will know that the parameter may be tool specific. - This is exactly what we want to tell the user. - Ambrish: You're saying add something to the spec that tells the model maker to put something in the description string? - Radek: Yes, we may suggest that. - Arpad: That's not enforceable by the parser. - Radek: It's a good place to put the information anyway. - Arpad: That is one good idea. What should the verbiage be for this? - I would like more. - Ambrish: In the section defining "Model Specific" parameters we could add, "if these parameters are used for any other purpose that may change the behavior of the model and affect the results, then..." - John: Usage says whether the user provides the info to the .dll, or the .dll gives it back, or it's for the tool/user (Info). - If a model maker intends to eventually make a parameter Reserved, and the aim is to inform the tool of something, then its usage is Info. - The parser or tool could catch Model Specific Info parameters and note that they might not be portable. - But another option would be an Out parameter that is intended to be Reserved eventually. If we have an Out in a Model Specific branch then that does not indicate anything special to the parser. - So is parser flagging on Usage alone adequate? - Arpad: If we explain in the spec that Model Specific parameters are intended to be used by the model, why would we have Info? - Info is typically for the tool? So should we prohibit them? - John: We are contemplating notification, not prohibition. - Walter: When we created this it was explicitly stated that the intent of Model Specific Info parameters was to let people develop advanced capabilities and advance the standard in a way that the parser would not fail. - So we can't now say that it's not going to be allowed. - Arpad: I understand, but if that is the purpose of this then we should not explain in the spec that Model Specific parameters are for the models. - They are also intended for the tools (Info). - Walter: No, it is intended for the user (Info). - If it's something the EDA tool can use, okay, but I think it's for the user and the user controls the tool. - Bob M: If there's a pressing need for EDA platforms that might not be in the know then what we want might be some set of Model Specific data types, for example InfoInOut, that informs any other EDA platform that this parameter might have proprietary uses elsewhere. - To require some explanation in a description field that isn't going to be parsed anyway seems to be above and beyond. - What we need is a warning about a model that appears to have secret handshakes with certain tools. - I think we've said there's no reason to have a Model Specific Info parameter other than a secret handshake. - John: Model Specific In parameter is okay. - Model Specific Info parameter is guaranteed to be a secret handshake. - Model Specific InOut or Out is indeterminate. - Ambrish: That's not really true. - Nothing is guaranteed with Model Specific parameters. - Even if you ban Info, nothing prevents a model maker from doing it with In. - So it doesn't preclude anything, even if we add a bunch of new types. - Bob M: But if a model maker wants to play nicely with the standard, if he has a secret handshake with a tool they could use InfoInOut. - It's to my advantage as a model maker to be able to tell the user if a model only works on a subset of tools. - John: If we have a way to parse and identify those parameters that might be proprietary then we get what we want. - Bob M: I ask that we please keep it simple so it doesn't become burdensome going from proprietary to approved Reserved parameter. - Ambrish: That doesn't help, you still have old models out there after the spec is updated, or the parameter is rejected. - Bob M: The model is still out there, but the tool can tell the user. - The tool could also update its warnings over time. - Arpad: What if we have verbiage to state that under the Model Specific section model makers could develop parameters that are specific to certain tools, and that they my then not be able to expect portability? - Then you don't have to define specifics? - John: That stops short of giving the tool a way to parse, find, and notify the user about such parameters. - Arpad: Then we could add another section, "It is strongly encouraged that model makers work with the spec to eventually make such parameters Reserved so that portability can be achieved." - Bob M: Instead of new types, what if we added another Model Specific Info parameter that calls out the use of proprietary Info. - John: You mean a Model Specific Info parameter that lists the proprietary parameters? - Bob M: Or just a single value 0 or 1. - Arpad: This "proprietary" parameter would be Reserve parameter though, right? - Bob M: It could be. - John: You could require secret params to be put in the Reserved parameters. - Then the parser can flag any whose name it doesn't know. - Ambrish: You could still just do it with a comment. It's still voluntary. - Arpad: I see the benefit of putting unrecognizable stuff in Reserved. - But then the user might have to edit the file to get rid of it? - If you take the "comment it out" approach, then what is the point of Model Specific? - John: The Model Specific branch does not generally have secret stuff. - Ambrish: Model Specific is for the model, period. - Arpad: You say that, but Walter says it's for innovation purposes. - Ambrish: Walter says that it is for the model, but for innovation purposes we don't preclude it being used by the tool. - Walter: If you eliminate Info it doesn't solve anything. You could just make them In. - It's the model maker's responsibility to make sure they don't have super secret handshake parameters. - Model makers don't do that, they usually document the issue. - Arpad: It's not a question of whether it's secret. - It's whether it's described by the spec or not. - Walter: We've been doing this for 10 years and haven't run into this problem of EDA tool specific parameters being released without notification. - Radek: We always come back to this topic of how to lead and how to change. - We have already agreed the issue is just notification. - "Proprietary" Reserved parameter, or info in the description, the focus should just be on the best way to do it. - The best way is to say, the standard describes the syntax, if the syntax is okay it's compatible. If there's any way of handling Model Specific parameters that will influence the simulation then it should be made clear to the user. - John: You're saying we should be in agreement to have a parseable means of notifying the user? - Bob M: I think we're in agreement on that. - The EDA tool should be able to make the user aware that there may be something in the model that it might not understand. - John: As opposed to just asking for descriptive text from the model maker? - Radek: Usually the descriptive string is quite visible in the file or GUI. - It should be sufficient, but it's not enforceable. - John: Nothing is enforceable, but do we want parseable notification or description? - Radek: Description would still be good even with a parseable warning. - John: Perhaps we want a "note" or "caution", not a warning. - Here's notification that we might not support this parameter right now. - Bob M: What if we had a Reserved parameter called "Interoperability" of type List. It could default to "all" or the value could be set to "limited" if necessary (not calling out particular tools). - David: What if you list the advanced features your model supports (not list specific tools)? - To Walter's point, history suggests these are announced well in advance. - Bob R: There's no requirement to make people do that. - It's noble that some do give advance warning. - Bob M: I could support a Reserved parameter "Interoperability" that was a list of all Model Specific parameters that are special. - Mike L: One Reserved parameter for the whole model, or a Model Specific leaf? - Bob M: Both have been proposed. - Mike L: Based on the name of the parameter, tools will know if they know what to do with it or not. - Arpad: What if the new parameter were "Proprietary", and the value is the name of the parameter. - Then, if it gets added as a Reserved parameter later, the tool would know if it already knows how to use it. - Bob M: Then it would need to be a List. - Walter: We could have a true/false "Interoperability" parameter. - If it's false then it means that it has some parameters that are not supported in the standard but the model maker expects the tool to do something based on the value of the parameters. - It would not have to list the parameters. - Arpad: But if the spec later implements the features, how would we know this flag is valid or not? - Walter: It's still valid if the params are in Model Specific and not Reserved. - Arpad: People often don't update their old models. - So that old model would stay the same way. - Based on your earlier comments about ease of promoting parameters to Reserved, we could establish a rule that if you find a Model Specific parameter with a Reserved name then the tool can use it. - Walter: That won't work because the parameter names often change multiple times during development. - Bob M: Once the new spec is in place, I want to update my model to reflect the new standard. - Arpad: Not everyone does that. - Just this week I got a newly updated model that still used IBIS 5.0. - Walter: You can't legislate quality. - Arpad: Have we managed to find something reasonable to everyone? - Should we continue this next week? - Ambrish: Even with everything we've talked about today, if there's a model that goes to a customer today nothing bounds things to help the user or tool know if there's anything special about the model. - Mike L: We need another meeting. - Arpad: Now is a good stopping point. - Thank you all for joining. ------------- Next meeting: 01 September 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives